Complexity of the management of today's network of software and hardware offerings, also known as a solution, sets forth new challenges for solution management systems. By definition, solutions are collections of software and hardware components that are brought together to address customers' business requirements. The complexity of these solutions and the skills required to operate and maintain such systems require automation and management. Such automation and management requires mechanisms for the participating components to communicate their operation status to the solution manager. Current advents in computing systems provide mechanisms for software or hardware products to communicate different aspects of their operation status, for example, configuration, performance, resource consumption, and significant changes in their normal operation or environment, generally referred to as events. The data collected is vital to a management system intended to monitor, regulate and ensure continuous operation of a solution. Such data collection is even more critical for autonomic computing and automation.
One prevalent problem in a complex and heterogeneous solution is the diversity of the types and formats of messages generated by participating components. Different components of a solution may be developed by different teams without an integrated program design. As such, the messages are composed and formatted as they are perceived to be the best fit by the respective development teams. Commonly, management systems provide adapters or connectors capable of receiving and parsing data based on some predefined rules to convert the data into a common format. Problems arise in a high frequency transaction environment where high volume of incoming messages must be matched against every parsing rule, top-down or bottom-up order, to find the right match. This can be a long and time consuming process that commonly imposes bottle necks and performance implication. In a high frequency transaction environment, a mechanism is desired to reduce the time required to traverse the parsing rule in search of the right match.
Another disadvantage of the prior efforts is that in a high frequency transaction environment, especially a heterogeneous and dynamic transaction environment, knowledge required for converting an event to a common format for purposes of, e.g., correlation and analysis, may not be readily available at a processing node. In addition, even if the knowledge can be made available at all processing nodes, the performance overhead of traversing the body of knowledge at every processing node is too high to be feasible in a production setup as millions of events flow into a processing node every second.
Still a further disadvantage of the prior efforts is that the knowledge required to do a conversion may not even have been constructed for various reasons. This is particularly true for applications and business processes which contain multiple sub-components and sub-processes put together in a dynamic fashion on a particular processing mode.
Based on the above, it is preferable that rules for converting an event can be distributed among separate processing nodes, and a rule set for converting an event can be dynamically generated.